Did any one find a proper solution?
Post
Replies
Boosts
Views
Activity
Thanks
Submitting crash report: FB9523755 (Crash in ios15 beta EXC_CRASH (SIGKILL))
Thanks @eskimo
ok I got an additional crash report from the customer with some more insight. The previous crash report is almost identical to the current one (so I will attach the most significant difference ).
Its also reproducible on iOS 14.6
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Termination Reason: Namespace SPRINGBOARD, Code 0x8badf00d
Termination Description: SPRINGBOARD, <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:scene-update watchdog transgression: application<com.glip.mobile.rc>:2931 exhausted real (wall clock) time allowance of 10.00 seconds | ProcessVisibility: Background | ProcessState: Running | WatchdogEvent: scene-update | WatchdogVisibility: Background | WatchdogCPUStatistics: ( | "Elapsed total CPU time (seconds): 7.820 (user 4.990, system 2.830), 13% CPU", | "Elapsed application CPU time (seconds): 0.091, 0% CPU" | ) reportType:CrashLog maxTerminationResistance:Interactive>
Triggered by Thread: 0
Now it seems that what cause the crash is some additional work that happens before the work during when the crash was reported.
I have read the following apple explanation
But I am still not 100% sure, in addition I noticed:
Elapsed application CPU time (seconds): 0.091, 0% CPU - that's look like a plausible time to avoid the crash BUT maybe it doesn't take in to account some additional previous time .
Any insights are welcome
@eskimo
Sorry I didn't find how to add additional crash log to the initial question so I am adding it here
TerminationReasonObfuscated.txt
How do I reproduce this kind of issues on my side? I mean I found some time consuming code that maybe responsible for it (its not part of the stack trace), but even though I add additional long calculation into it, it doesn't crash.
Maybe it happens only on device? production mode?
Thanks
@eskimo
Thanks a lot, indeed the issue was caused by sort of complex dead lock, its almost like u described just in my case the background thread after getting the lock was asking main thread in sync way to execute some logic , mean-while a main thread also asked the same lock, but the background thread never released his lock as main thread was not available to execute his logic
Xcode 13.2.1 the problem still exists (swift code): why? :(
`po $arg1
error: <EXPR>:8:1: error: cannot find '$arg1' in scope
$arg1
^~~~~
(lldb) register read -A
General Purpose Registers:
rax = 0x0000000000000036
rbx = 0x00007fa8a0f081e0
arg4 = 0x0000000000000000
arg3 = 0x0000000000000000
arg1 = 0x00007fa8a0f081e0
arg2 = 0x00007fff6dd7499e
fp = 0x00007ffeef3b6f30
sp = 0x00007ffeef3b6f20
arg5 = 0x00007fff864a40a0 libsystem_pthread.dylib`_pthread_keys
arg6 = 0x00007fa8a483bc90
r10 = 0x00000001008562a8 (void *)0x0000000100857588: _TtC6***29XXXViewController
r11 = 0x00007fff248cd65c UIKitCore`-[UIViewController(UIKitManual) release]
r12 = 0x0000000000000278
r13 = 0x00007fa8a0f081e0
r14 = 0x0000000000000000
r15 = 0x00007fff201833c0 libobjc.A.dylib`objc_msgSend
pc = 0x000000010084a8e4 ***`***.***.Controller.setup() -> () + 20 at ViewController.swift:33:9
flags = 0x0000000000000202
cs = 0x000000000000002b
fs = 0x0000000000000000
gs = 0x0000000000000000
(lldb) po $arg1
error: <EXPR>:8:1: error: cannot find '$arg1' in scope
$arg1
^~~~~`
Any progress on it?
Having the same issue, any progress iOS 15.2
Same issue here
Having the same(similar) issue: the SDK is build with Xcode14 but for is failed to build on Xcode 13.
"Failed to build module 'OURSDK'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.7 (swiftlang-5.7.0.120.1 clang-1400.0.28.1)', while this compiler is 'Apple Swift version 5.6.1 (swiftlang-5.6.0.323.66 clang-1316.0.20.12)'). Please select a toolchain which matches the SDK
The module stability is from 5.1 so there should not be an issue
Same issue
Same issue
Pendo SDK had a great progress in coddlers analytics for swiftui:
https://github.com/pendo-io/pendo-mobile-sdk/blob/master/ios/pnddocs/swiftui.md
any progress on it ?
I dont agree that in all cases the problem are the tests.
For Instance we use OCmock and create partial mocks for objects. and that's cause us a lot of issues when different tests mocking/using the same objects simultaneously.
When u have a multiple developers trying to test same region, there is good chance of race conditions between the tests accessing same area of code/ resources what what won't really happen in simple user flow